fix: stop reading the filesystem from ordinary string parameters - #3

The SDK walked every string in the params of run(), imageUpload() and
mediaStorage(), and replaced any string that was an exact path to a readable
regular file with that file's base64 contents. There was no field allowlist, so
positivePrompt was treated the same as seedImage: an application that
forwarded user text into run() could be made to read local files and send them
upstream.

The README already described the contract it was meant to honor, and did not:
"and prompts pass through untouched".

What changes

The recursive walk is gone. A string you pass is sent as that string.

A local file now travels only when the caller asks for it, which is the property
that was missing: the filesystem is reached by naming a function, never by a
value happening to look like a path.

The explicit way, unchanged

file_to_base64 and file_to_data_uri already took a str, a Path, bytes
or a file-like, so the migration is a drop-in:

# before
await client.run({"model": "...", "seedImage": "./photo.jpg"})

# after
await client.run({"model": "...", "seedImage": file_to_base64("./photo.jpg")})

file_to_base64 returns raw base64 with no prefix, which is byte-for-byte what
the implicit encoder put on the wire.

Breaking

Passing a path straight to a media parameter no longer works. That behavior was
advertised in the README, so this is a breaking change for anyone using it
deliberately, shipped as a patch because leaving people on a vulnerable version
is worse. The migration is the one line above.

Verification

• The case that leaked: a prompt that is an exact path to a real file now reaches
  the transport as that path, and the file's base64 appears nowhere in the body.
  Asserted at top level and nested in an array.
• The explicit helpers still encode, from a path, from bytes, and from a Blob.
• Full suite, lint and typecheck green.